User blog:SquareFingers/Disappointed in PTC...
I recently found a second bug in PTC, which I wrote about here: 0.999995 (Numerical Value) (the first I wrote about in -0 (Numerical Value)). This, along with other aspects of the design (like using the value 1 for TRUE, rather than -1), makes me really hope that SmileBoom got some mature developers for V3. Another issue I have found is the fact that PRINT apparently takes any number of parameters (values) without delimiters, and will output one immediately after another. So, ?4 5 is a ? (shorthand for PRINT) with two values following it, 4 and 5, and the output is... 45. It allows for some shorthand, such as ?"A"2"B" will give the result A2B shorter than using the explicit delimiter ; in ?"A";2;"B", but that's a very minor benefit at best, and it has other side-effects that are confusing. For fun, I tried ?&H1G. I expected a syntax error (because that's what you get when &H1G is used in other parts of a program, such as in an assignment like V=&H1G), or some other kind of error. Instead, I got 10. What happened was that the interpreter sees &H, takes as much of the following input as represents a hexadecimal value (1), and stops. That leaves G. So, what I typed was interpreted the same as ?&H1 G, or ?&H1;G. Since I had not initialized the variable G to anything, reading it gives the value 0, and ?&H1G gives 10. Next, I tried ?&H10.8. I expected either a syntax error, meaning the &H recognized that there was a fractional component to the value but was designed only to work on integer values, or 16.5, meaning the &H recognized that there was a fractional component to the value and converted that fractional value as if it were expressed in hexadecimal. I feared I would get 16.8. Instead, I got 160.8. What really happened is that &H recognised that there was a character it didn't want to interpret - the . character - so it stopped interpreting at 10. This left .8 as a 'second parameter' to ?, which gets printed as 0.8. So, ?&H10.8 was ?&H10 .8 or ?&H10;.8 giving 160.8. Obvious, not. (V=&H10.8 also makes a syntax error.) Fixed-point representations for numerical values. No need for a closing " at the end of a line where the last syntactic element is a string literal. Mistakes in the documentation (such as GPAGE screen drawing pagedisplay page where it should be GPAGE screen drawing page, display page). LINPUT with more than one string variable is a syntax error, but instead of reporting the error right away, the system first tries to do something it should know it cannot succeed at (get two or more line inputs from the user in one line). No ON ERROR. While some of these design decisions are merely unconventional (or lazy), rather than stupid or wrong, the weight of evidence is that the design is really quite careless. I'm beginning to question my commitment to buy V3, unless there's some sign that the design team has grown up a bit and made sensible decisions and implemented them properly and thoroughly. (Yes, the purpose of this blog is really only to get the badge(s). In fact, I don't doubt that I'll buy V3 the day I hear it's available.) Category:Blog posts